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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Telecommunications and Internet 
converged Services and Protocols for Advanced Networking (TISPAN). 
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Scope 



The present document specifies the protocol that is used by the local emergency operator to obtain the location 
information that is registered on the operator location server. It endorses and defines a profile of the LIF specification 
TS 101 [1] that are applicable to the emergency location information services. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

[1] LIF TS 101 Specification (v3.0.0): "Location Inter-operability Forum (LIF); Mobile Location 

Protocol". 

NOTE: Available at http://www.openmobilealliance.org/ notes/main/lifdownload.html 

[2] EPSG Geodesy Parameters: "EPSG Geodetic Parameter Data Set Version 6.3". 

NOTE: Available at http://www.epsg.org/ . 

[3] Nice Specification NDI013:2002/1 1: "Emergency Location Information Interface". 

NOTE: Available at: http://www.nicc.org.uk/ . 

3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

emergency location immediate service: service used for querying of the location of a mobile subscriber that has initiated an 
emergency call 

NOTE: The response to this service is required immediately (within a set time). 

emergency location reporting service: service that is used when the wireless network automatically initiates the 
positioning at an emergency call 

NOTE: The position and related data is then sent to the emergency application from the location server. Which 
application and its address are defined in the location server. 

local emergency operator: designated emergency operator that can use the a Mobile Location Protocol operated by a 
location-based application to request MS location information from an operator location server 

operator location server: location server with in the PLMN that, in the event of an emergency situation, a designated 
emergency operator can use the a Mobile Location Protocol to request MS location information from. 

NOTE: An Operator Location Server may be a GMLC/MPC or other entity in the wireless network. 
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3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

A-GPS Assisted Global Positionning System 

APSG Americas Petroleum Survey Group 

EOTD Enhanced Observed Time Difference 

EPSG European Petroleum Survey Group 

FFS For Further Study 

ISO International Standards Organization 

LCS Local Contact Service 

LIF Location Interoperability Forum 

MLP Mobile Location Protocol 

MNO Mobile Network Operator 

MSC Mobile Switching Centre 

MSISDN Mobile Subscriber ISDN Number 

POSC Petrotechnical Open Software Corporation 

QOP QuaUty Of Position 



MLP Lite 112 



The present document: 



Identifies the clauses of the LIF TS 101 Specification [1] that are applicable to the emergency location 
information services. 

Does not identify how the mobile network operator determines location. 

Does not identify how the location information is passed between the emergency operator and the appropriate 
emergency authority. 

Does not identify how the location information is passed between the emergency operator and the appropriate 
emergency authority. 

Does not describe how the emergency call is established. 
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Scope of the present document 




. Note: the PSAP and Emergency Control Centre 

call path ^^y ^g co-located 

■* Location information path 



Figure 1 : Scope of the present document 

The LI Forum has been affihated and its work subsumed into the OMA, see the description of the OMA affiUates: 
http://www.openmobileaniance.org/ notes/main/affiHates index.html and the press release on the availability of the 
LIF MLP specification, see: http://www.openmobilealliance.org/ notes/main/lifpress2.html . 

Please see LIF TS 101 Specification [1] full LIF specification at 
http://www.openmobilealliance.org/ notes/main/lifdownload.html for further details and information. 

Note that in this implementation of the LIF MLP protocol: 

• ALL compulsory LIF elements are compulsory. 

• Some optional LIF elements are compulsory. 

Annex C lists a number of features, clause C.l is an example of a current implementation, clauses C.2 to C.6 are for 
further study in future release of the MLP specification at OMA. 



Name and address data 



The LIF MLP [1] standard does not include name and address type fields but does include an extension mechanism to 
allow additional elements to be added. 

A name and address extension is included in this specification to enable fixed line operators to adopt the same protocol 
as mobile operators to provide location information to emergency services: 

• Potential data sources to populate these fields include: 

installation address for fixed lines phones; 

addresses "reverse geocoded" from latitude, longitude position of mobile handset; 

location of pico cells within buildings. 
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Note that the referenced extension (and therefore the structure and elements within this extension) could be different for 
different countries, different operators and different emergency services. 

EXAMPLE: If required the name and address fields and field formats could be defined differently to suit 
different countries, different operators or different emergency services. 



LIFTS 101 V3.0.0 Endorsement 



This specification is a profile of and is based on the interface defined by the Location Interoperability Forum (LIF). The 
following table identifies clauses within the LIF specification, and clarifies which options are applicable to a emergency 
location information service. 

This specification identifies the minimum requirement. Elements not explicitly detailed in this clause should be 
considered to be "Not required". Additional optional elements may be implemented on a bilateral basis. 

NOTE: In the following table, the term: "is required to be supported" is equivalent to "shall contain". However, it 
is understood that the definition of "is required to be supported" provides more clarity and detail than the 
definition of "shall contain" as the definition is captured from clause 0.7.2 of the PNO-ISC Specification 
013 [3]. 



LIFTS 101 [1] 
section 


Title 


Profile requirement 


1 


Revision History 




2 


Introduction 




3 


General 




3.3 


MLP extension mechanism 


Required 


4 


Mobile Location Service 
Definitions 




4.1 


Transport Protocol Layer 
Definitions 


Required (See endorsement of Annex B of [1]) 


4.2 


Element Layer Definitions 




4.2.1 


Identity Element Definitions 


The following elements are required to be supported, and where an 
element is a construction, which elements are required to be 
supported within the construction: 

• msid 

• msid 

o msid 
One msid element shall be included in an msids element) 


4.2.3 


Location Element Definitions 


The following elements are required to be supported, and where an 
element is a construction, which elements are required to be 
supported within the construction: 

• eme_pos 

o msid 
pd 
o poserr 

• pd 

o time 
shape 
o levconf 

• poserr 

o result 
o time 

• result 

• time 

• lev_conf 
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LIFTS 101 [1] 
section 


Title 


Profile requirement 


4.2.4 


Shape Element Definitions 


The following elements are required to be supported, and where an 
element is a construction, which elements are required to be 
supported within the construction: 

• shape 

o EllipticalArea 

• AngularUnit 

• Angle 

• Coord 

o X 
o Y 

• X 

• Y 

• EllipticalArea 

o Coord 
o Angle 
o SemiMajor 
o SemiMinor 
o AngularUnit 

• SemiMajor 

• SemiMinor 


4.2.7 


Context Element Definitions 


The following elements are required to be supported, and where an 
element is a construction, which elements are required to be 
supported within the construction: 

• Client 

o Id 

o Pwd 

o Requestmode 

• Id 

• Pwd 

• Requestmode 

• servicetype 


4.3 


Service Layer Definitions 




4.3.1 


Header Components 




4.3.1.1 


Context DTD 


The following elements are required to be supported, and where an 
element is a construction, which elements are required to be 
supported within the construction: 
• hdr 

client 


4.3.3 


Emergency Location Immediate 
Service 


Required 


4.3.3.1 


Emergency Location Immediate 
Request DTD 


The "emejir" shall contain the following element: 
• msids 


4.3.3.2 


Emergency Location Immediate 
Answer DTD 


The "emejia" shall contain the following elements: 

• emejDos, or 

• result 

• caller location (optional) 


4.3.5 


Emergency Location Reporting 
Service 


Required 


4.3.5.1 


Emergency Location Report 
DTD 


The "emerep" shall contain the following elements: 

• eme_event 

• caller location (optional) 


4.3.7 


General Error Message 
Definition 


The "gem" shall contain the following elements: 
• result 


5 


Elements and attributes in 
DTD 




5.4 


angle 


Required 


5.5 


angularUnit 


Required 


5.17 


EllipticalArea 


Required 


5.18 


eme event 


Required 


5.18.1 


eme trigger 


Required 


5.23 


id 


Required 


5.27 


lev conf 


Required 


5.37 


msid 


Required 


5.37.1 


Type 


Type shall be "MSISDN" 
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LIFTS 101 [1] 
section 


Title 


Profile requirement 


5.37.2 


enc 


Enc shall be "ASC" 


5.49 


pwd 


Required 


5.54 


result 


Required 


5.55 


semiMajor 


Required 


5.56 


semiMinor 


Required 


5.58 


requestmode 


Required 


5.58.1 


type 


Type shall be "PASSIVE" 


5.66 


time 


Required 


5.72 


X 


Required 


5.73 


Y 


Required 


5.75 


Service attributes 




5.75.2 


ver 


Required 


6 


Result codes and error codes 




6.1 


Result codes 


Required 


7 


References 






References (normative) 






References (informative) 




8 


Appendix A (informative) : 
Adaptation to 3GPP LCS 




9 


Appendix B - HTTP mapping 


The lif-mlp-s (921 1/tcp) port or the lif-mlp (921 0/tcp) port shall be 
used. 

Location client shall use separate HTTP posts and NOT use 
pipelining for time critical requests to avoid that one request delays 
other requests. Location Server shall process and respond to the 
separate H 1 1 P posts out of order. 


9.2.1 


Service Initiation DTD 


The "SVC init" shall contain the following elements; 

hdr 

erne Mr 


9.2.2 


Service Result DTD 


The "svc"_result shall contain the following elements: 

emejia 

emerep 



6.1 Result codes (LIF defined) 

This table defines the resuh codes that indicate the result of the request or individual positioning 
The error codes are divided in ranges: 



0to99 


Location server specific errors 


100 to 199 


Request specific errors 


200 to 299 


Network specific errors 


300 to 499 


Reserved for future use 


500 to 599 


Vendor specific errors 



NOTE: For privacy reasons it might be needed to not report certain specific errors. In this case it is up to the 
implementation or configuration of the location server which errors will be reported. 

These are the errors defined in LIF ML? V3.0.0. [1]. They may well change in later versions. 
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Resid 


Slogan 


Description 





OK 


No error occurred while processing the request 


1 


SYSTEM FAILURE 


The request can not be handled because of a general problem in the 
location server or the underlying network 


2 


UNSPECIFIED ERROR 


An unspecified error used in case none of the other errors applies. 
This can also be used in case privacy issues prevent certain errors 
from being presented 


3 


UNAUTHORIZED APPLICATION 


The requesting location-based application is not allowed to access the 
location server or a wrong password has been supplied 


4 


UNKNOWN SUBSCRIBER 


Unknown subscriber. The user is unknown, i.e. no such subscription 
exists 


5 


ABSENT SUBSCRIBER 


Absent subscriber. The user is currently not reachable 


6 


POSITION METHOD FAILURE 


Position method failure. The location service failed to obtain the user's 
position 








101 


CONGESTION IN LOCATION 
SERVER 


The request can not be handled due to congestion in the location 
server 


102 


CONGESTION IN MOBILE 
NETWORK 


The request can not be handled due to congestion in the mobile 
network 


103 


UNSUPPORTED VERSION 


The Location server does not support the indicated protocol version 


104 


TOO MANY POSITION ITEMS 


Too many position items have been specified in the request 


105 


FORMAT ERROR 


A protocol element in the request has invalid format. The invalid 
element is indicated in ADD INFO 


106 


SYNTAX ERROR 


The position request has invalid syntax. Details may be indicated in 
ADD INFO 


107 


PROTOCOL ELEMENT NOT 
SUPPORTED 


A protocol element specified in the position request is not supported 
by the Location Server. The element is indicated in ADD INFO 


108 


SERVICE NOT SUPPORTED 


The requested service is not supported in the Location Server. The 
service is indicated in ADD INFO 


109 


PROTOCOL ELEMENT ATTRIBUTE 
NOT SUPPORTED 


A protocol element attribute is not supported in the Location Server. 
The attribute is indicated in ADD INFO 


110 


INVALID PROTOCOL ELEMENT 
VALUE 


A protocol element in the request has an invalid value. The element is 
indicated in ADD INFO 


111 


INVALID PROTOCOL ELEMENT 
Al IKIBUTE VALUE 


A protocol element attribute in the request has a wrong value. The 
element is indicated in ADD INFO 


112 


PROTOCOL ELEMENT VALUE NOT 
SUPPORTED 


A specific value of a protocol element is not supported in the Location 
Server. The element and value are indicated in ADD INFO 


113 


PROTOCOL ELEMENT ATTRIBUTE 
VALUE NOT SUPPORTED 


A specific value of a protocol element attribute is not supported in the 
Location Server. The attribute and value are indicated in ADD INFO 


201 


OOP NOT ATTAINABLE 


The requested OoP cannot be provided. 


202 


POSITIONING NOT ALLOWED 


The subscriber does not allow the application to position him/her for 
whatever reason (privacy settings in location server, LCS privacy 
class). 


204 


DISALLOWED BY LOCAL 
REGULATIONS 


The location request is disallowed by local regulatory requirements. 


207 


MISCONFIGURATION OF 
LOCATION SERVER 


The location server is not completely configured to be able to 
calculate a position. 


300 

to 

499 




Reserved for future use 


500 

to 

599 




Vendor specific errors 
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7 



MLP extension 



This clause details an optional MLP extension. This provides a simple mechanism to transport name information and a 
freeform textual description of location, see [3]. 

Support of this extension is not mandatory. 



7.1 Data type definition 



< ! — pno-isc^ 


_MLP 


_extension — > 










<! ENTITY 




% extension .param 


' caller_location? ' > 






<! ELEMENT 




caller location 




(customer_name?, Address 


_linel?, Address 


Iine2?, 






Address„line3?, 


Add 


ress_line4?, Address„line5?, 


Address„line6?, 


postcode?) > 


< ! ELEMENT 




customer_name 




(#PCDATA)> 






< ! ELEMENT 




Address_linel 




(#PCDATA)> 






< ! ELEMENT 




Address_line2 




(#PCDATA)> 






<! ELEMENT 




Address_line3 




(#PCDATA)> 






<! ELEMENT 




Address_line4 




(#PCDATA)> 






<! ELEMENT 




Address_line5 




(#PCDATA)> 






< ! ELEMENT 




Address_line6 




(#PCDATA)> 






<! ELEMENT 




postcode 




(#PCDATA)> 







7.2 



Elements and attributes 



7.2.1 Customer name 



Description: 


Specifies tine name of the customer associated with the geographic info 


Format: 


Char String 


Defined values: 


- 


Default value: 


- 


Example: 


<customer_name>MrBenn</customer_name> 



7.2.2 Address linel 



Description: 


Specifies a line of text providing a freeform textual description of the associated location information 


Format: 


Char String 


Defined values: 


- 


Default value: 


- 


Example 1 : 


<Unel>52 Festive Road</linel> 


Example 2: 


<Hnel>Heathrow Terminal 4 Checlc In Desks</linel> 


NOTE: No formatting of the address should be assumed i.e. a full postal address could be defined 
using one line element, or split over several lines using the linel , Iine2, lineS etc elements. 



7.2.3 Addressjine2 

As 7.2.2 

7.2.4 AddressJineS 

As 7.2.2 
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7.2.5 Addressjine4 

As 7.2.2 

7.2.6 AddressJineS 

As 7.2.2 



7.2.7 

As 7.2.2 



Address Iine6 



7.2.8 Postcode 



Description: 


Specifies tine postcode associated with the location information 


Format: 


Char String 


Defined values: 


- 


Default value: 


- 


Example: 


<postcode>SWl lAA</postcode> 


NOTE: Can be used in the case that the postcode is known (e.g. in-building, pico cell coverage). 



7.3 Examples of usage 

For examples of the use of these this MLP profile and extensions, see Annex A. 



8 



European Petroleum Survey Group 



The European Petroleum Survey Group (EPSG) was formed in 1986. It comprises specialist surveyors, geodesists and 
cartographers from European Oil Companies. Meetings are held twice yearly to discuss survey and positioning topics 
within those areas of oil industry business where cooperation is generally agreed to be mutually beneficial. 

A geodesy working group maintains a relational database of EPSG geodetic parameters. 

The EPSG aims to help member companies, and where relevant others, by the dissemination of information which by 
generally improving oil industry survey practices and procedures, will contribute to increased efficiency, enhanced 
quality, improved safety of operations and the protection of the environment. 

Through its membership of specialist professionals, the EPSG is qualified to offer collective expert advice to member 
companies within the fields of geodesy, surveying, positioning and cartography where they relate to oil exploration, 
development and production operations, see Annex B of the present document. 
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Annex A (informative): 
Example messages 



This annex provides example message formats associated with the defined sub-set of the LIF specification described in 
the present document. 



A.1 Emergency location immediate request 



<?xml version=" 1 . 0" ?> 

<!DOCTYPE svc_init SYSTEM "MLP_SVC_INIT_300 . DTD"> 
<svc_init ver="3.0.0"> 
<hdr ver="3.0.0"> 
<client> 

<id>emergency operator</id> 
<pwd>bigcrash</pwd> 
<requestmode type="PASSIVE" /> 
</client> 
</hdr> 
<eme_lir ver="3.0.0"> 

<msids> 

<msid type="MSISDN">447770123123</msid> 



</msids> 
</eme_lir> 
</svc_init> 



Service initiation for IVILP Version 3.0.0 

Header for IVILP Version 3.0.0 

Who is requesting this location fix 

Emergency operator registered user name for login 

Emergency operator password for login 

Its not the ACTIVE user requesting a location fix 



Emergency Location Immediate Request for MLP 

Version 3.0.0 

Identifier of device to be located 

Identifier is a MSISDN formatted as Country Code 

+ Phone Number (GSM/3GPP should conform to 

TS 1 23 003) 



A.2 Emergency location immediate answer - valid 
response 

<?xml version=" 1 . 0" ?> 

<!DOCTYPE svc_result SYSTEM "MLP_SVC_RESULT_300 . DTD" [ 
<!ENTITY pno-isc_MLP_extension ' pno-isc_MLP_extension . dtd' > 
]> 

<svc_result ver="3.0.0"> 
<eme_lia ver="3.0.0"> 



<eme_pos> 

<msid type="MSISDN">447770123123</msid> 



<pd> 



<time utc_off="+0100">2 002 07 02115712</time> 

<shape> 

<EllipticalArea> 

<coord> 

<X>N51 .514</X> 

<Y>W0.102</Y> 

</coord> 

<angle>90 . 00</angle> 

<semiMa jor>50</semiMa jor> 
<semiMinor>2 5</semiMinor> 



Service result for MLP Version 3.0.0 

Emergency Location Immediate Answer for 

MLP Version 3.0.0 

Position answer 

Position is for this MSISDN (formatted as 

Country Code + Phone Number) (GSM/3GPP 

should conform to TS 123 003) 

Position description 

Local Date and Time of phone when position 

was measured. 

Shape of uncertainty area 

lt"s an ellipse (on the WGS-84 co-ordinate 

reference system as default). 

Coordinate of the centre of the ellipse 

Latitude in decimal degrees prefixed with N or 

S 

Longitude in decimal degrees prefixed with E 

orW 

Angle in degrees of rotation of the ellipse 
measured clockwise from north 
Length of semiMajor axis in metres 
Length of semiMinor axis in metres 
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<angularUnit>00</angularUnit> 
<clistanceUnit>00</distanceUnit> 

</EllipticalArea > 
</shape> 
<lev_conf >80</lev_conf > 



</pd> 

</eme„pos> 

<caller_location> 

<Address_linel>2nd Floor </Address„linel> 
<Address_line2>Oftel</Address„line2> 
<Address_line3>50 Ludgate Hill<Address_/line3> 

<Address_line4>London</Address_line4> 

<postcode>EC4M 7 JJ</postcode> 
</caller_location> 
</eme_lia> 
</svc_result> 



Length of angularUnit in degrees 
Length of distanceUnit in metres 



Indicates the probability as a percentage that 
the phone is located within the position area 
defined 



Freeform textual description of location 
(e.g derived from pico cell coverage) 



A.3 Emergency location immediate answer - error 
response 



<?xml version=" 1 . 0" ?> 

<!DOCTYPE svc_result SYSTEM "MLP_SVC_RESULT_300 . DTD"> 
<svc_result ver="3.0.0"> 
<eme_lia ver="3.0.0"> 

<eme_pos> 

<msid type="MSISDN">447770123123</msid> 



</result> 



<poserr> 

<result resid="004"> UNKNOWN SUBSCRIBER 

<add„inf o>This space left blank</add_inf o> 
<time utc_off="±0 100 ">20020702 1157 12</time> 



</poserr> 
</eme_pos> 

</eme_lia> 



Service result for MLP Version 3.0.0 

Emergency Location Immediate Answer for 

MLP Version 3.0.0 

Position answer 

Position is for this MSISDN (formatted as 

Country Code + Phone Number) 

(GSM/3GPP should conform to TS 123 003) 

Error code number and error code text 

Additional information about the result 

Local Date and Time of phone when position 
attempt was made 



</svc_result> 



A. 4 Example usage of MLP extension 

<?xml version=" 1 . 0" ?> 

<!DOCTYPE svc„result SYSTEM "MLP_SVC_RESULT_300 . DTD" [ 

<!ENTITY pno-isc_mlp_extension ' pno-isc_mlp_extension . dtd' > 

]> 

<svc_result ver="3.0.0"> 

<eme„lia ver="3.0.0"> 



<eme_pos> 

<msid type="MSISDN">447770123123</msid> 



<pd> 



<time utc_off="+0100">2 002 07 02115712</time> 

<shape> 

<EllipticalArea> 



Service result for IVILP Version 3.0.0 

Emergency Location Immediate Answer for 

MLP Version 3.0.0 

Position answer 

Position is for this MSISDN (formatted as 

Country Code + Phone Number) 

(GSM/3GPP should conform to TS 123 003) 

Position description 

Local Date and Time of phone when position 

attempt was made 

Shape of Location Area 

It is an ellipse (on the WGS-84 co-ordinate 

reference system as default). 
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coord> 




<X>N51 


.459</X> 


<Y>WO. 


448</Y> 


/coord> 




angle>90 


. 00</angle> 
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Coordinate of the centre of the ellipse 

Latitude in decimal degrees prefixed with N 

orS 

Longitude in decimal degrees prefixed with 

EorW 

Angle in degrees of rotation of the ellipse 

measured clockwise from north 

<semiMajor>50</semiMajor> Length of somlMajor axis in metres 

<semiMinor>25</semiMinor> Length of somiMinor axis in metres 

<anguiarUnit>oo</anguiarUnit> Length of angularUnit in degrees 

<distanceUnit>oo</distanceUnit> Length of distancoUnit in metres 

</EllipticalArea> 
</shape> 

<iev_conf >80</iev_conf > Indicates the probability as a percentage 

that the phone is located within the position 
area defined 

</pd> 
</eme_pos> 
<caller_location> 

<Address_linel>Heathrow Terminal 4 check-in desks Freeform textual description Of lOCation. 

< / Addr e s s_l ine 1 > 

</caiier_iocation> (e.g derived from pico cell coverage) 

</eme_lia> 
</svc_result> 
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Annex B (informative): 

European Petroleum Survey Group and other notes 



B.1 EPSG Geodetic parameters 



The European Petroleum Survey Group (EPSG) was formed in 1986. It comprises specialist surveyors, geodesists and 
cartographers from European Oil Companies. Meetings are held twice yearly to discuss survey and positioning topics 
within those areas of oil industry business where cooperation is generally agreed to be mutually beneficial. 

A geodesy working group maintains a relational database of EPSG geodetic parameters. EPSG, through its geodesy 
working group, maintains and publishes a data set of parameters for coordinate system and coordinate transformation 
description. The data is supported through formulae given in guidance note number 7. The EPSG geodetic parameters 
have been included as reference data in the GeoTIFF data exchange specifications, in Iris21 (Petroconsultant's data 
model) and in Epicentre (the POSC data model). The parameters are maintained in an MS Access relational database 
and may be consulted on this site. 



B.2 EPSG guidance notes 



EPSG produces an occasional series of guidance notes for its member use. Some are made publicly available from this 

site. 

Associations with other organizations PSG has: 

• category A liaison membership of the International Standards Organization (ISO) Technical Committee 211, 
Geographic Information/Geomatics; 

• a strong, but informal, relationship with the UKOOA Survey and Positioning Committee; 

• a strong, but informal, relationship with the Petrotechnical Open Software Corporation (POSC) to which it 
provides geodetic advice and support through the EPSG geodesy working group; 

• EPSG geodesy working group members maintain a liaison with the Open GIS Consortium over spatial 
referencing and coordinate transformation; 

• EPSG maintains links with the Americas Petroleum Survey Group (APSG). 



B.3 EPSG Geodesy parameters V6.3 

In February 2002, the European Petroleum Survey Group (EPSG) completed and released the ISO-compliant 
version 6.1 data model and data set. The move to the new model was made to encourage standardization both across the 
Exploration and Production segment of the oil industry and in the geodetic community at large. Since that release, much 
new data has come available. 

This new Version 6.3 [2] is the current EPSG release, distributed in an MS Access 97 database. It incorporates data 
received and verified since the release of version 6.1. There are no changes in the data model from version 6.1. 

NOTE 1: Version 6.3 [relational] database is only available in MS Access v97 but can be converted to 
Access 2000. 

NOTE 2: This zipped file is comprised of the version 6.3 database (MS Access 97) and associated documentation 
(in both Adobe Acrobat PDF and MS Word 97-2000& 6/95-rtf formats). The zipped file is approximately 

2 Mb in size. 

There are no significant changes in content from the v6.2.2, v6.2.1 and v6.2 versions of the database that are superseded 
by this v6.3 database. Some changes were made primarily to form controls to assist user conversion to Access 2000. 
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B.4 Cell-ID based location performance 

When an emergency call is made, the 3GPP standards specify that the Cell-ID which is in use is stored - this is called 
INITIAL location in the standards and can be retrieved by a location server very quickly (typically about 1 s). 

A location server can also cause a handset to be paged and the Cell-ID currently in use to be obtained and stored. This is 
called CURRENT location in the standards. Because paging the handset takes time, this CURRENT location can only 
be retrieved by a location server after a longer time (typically 3-8 s?). 

As well as the retrieval time difference, the INITIAL location may well be different to the CURRENT location if the 
Caller is moving e.g. in a vehicle or train. 

Already offered, performance of current CelllD or CelllD at the start of call, differs in different network 
implementations and technology. 
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Annex C (informative): 
Proposed additional functionality 



Annex C lists a number of features, clause C.l is an example of a current implementation, clauses C.2 to C.6 are for 
further study in future release of the MLP specification at OMA. 



C.1 Circle location configuration - additional shape to 
ellipse 



LIFTS 101 [1] 
section 


Title 


Profile requirement 


5 


Elements and attributes in DTD 




5.10 


CircularArea 


Required 



Description: 


The set of points on the ellipsoid, which are at a distance from the point of origin less than or equal to "r". 


Type: 


Element 


Format: 


Char String 


Defined values: 


- 


Default value: 


- 


Example: 


<CircularArea srsName="www.epsg.org#4004" gid="some_thing"> 
<coord> 

<X>301628.312</X> 
<Y>451533.431</Y> 
</coord> 

<radius>240</radius> 
</CircularArea> 



As defined in MLP TS 101 [1] from LIF Forum. 



C.2 InBound roamers 



In summary the visited MNO needs to know which of their MSCs the InBound roamer is connected in order to enable 
their Cell-ID based location to be found. 

This would normally required the Visited MNO Operator to request this information from the InBound roamers Home 
MNO. 

The Swedish 112 Mobile Location standard requires the MSC number to be passed to the emergency operator entity in 
the "Location Number" field of an ISUP "Initial Address Message". 

The emergency operator entity can then pass this MSC Number to the visited network as part of the MLP message 
(standard optional field). 

Protocol compatibility issue, need to investigate the availability of ISUP v4 EN 300 356 (see bibliography). 
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C.3 Proposed additional functionality - position fix type 



C.3.1 Location technology selection 



An issue with the ideas in MLP Lite was that the request would not allow the requestor to specify which location 
technology to use if more than one was implemented by an operator. 

E.g. MNO implements both Cell-ID and Assisted GPS technologies. Cell-ID gives a quick inaccurate response whereas 
A-GPS gives a slow accurate response. The emergency operator may require both. E.g. Cell-ID based to initiate 
response despatch and then A-GPS to locate the caller more exactly. 

MLP 3.1 allows the "eqop" element (already defined for Standard Immediate requests) to be included in emergency 
immediate requests. 

Within "eqop" the element "resp_req" allows the Location technology required to be implied. 

Values of "resp_req" allowed are as follows 



NO_DELAY No delay: The server should immediately return any location estimate that 
it currently has. 



LOW_DELAY Low delay: Fulfilment of the response time requirement takes precedence 
over fulfilment of the accuracy requirement. 



DELAY_TOL DEFAULT - Delay tolerant: Fulfilment of the accuracy requirement takes 

precedence over fulfilment of the response time requirement. 



NOTE: The interpretation of these values is defined in TS 1 22 071 and TS 1 29 002. 



This parameter indicates what is important to the emergency operator (i.e. speed or accuracy) but how that is achieved 
within an MNO Domain with a particular User and a particular handset would be an implementation decision for each 
operator. 



C.3.2 Background 



From the proposed implementation of this functionality in July 2003 or soon after it is likely that some operators will be 
offering multiple position fix technologies. For example Cell-ID based plus EOTD and/or A-GPS. 

The emergency operator has two functional requirements: 

1) A very quick response to location request (accuracy not as important as response speed). 

This enables the emergency operator to route the call to the correct emergency authority based on approximate 
geographic location, to question the caller more appropriately to establish the exact location using approximate 
location details and in most cases to despatch the nearest response vehicle. 

2) A most accurate response to a location request (accuracy more important then response speed). 

This may be required if the emergency authority cannot determine exactly where the caller is, for example 
after talking to the caller. 

C.3.3 Issue 

In a network providing more than one location technology, (e.g. both Cell-ID and A-GPS) these two requirements 
require two different requests. 

By utilizing the standard LIE optional QOP parameters (e.g. horizontal accuracy and how long before a response is 
required) it may be possible for the emergency operator to request a Cell-ID fix and then a A-GPS fix but this would 
require the emergency operator to know the capabilities and necessary parameters for each network and each caller's 
handset and configure these in their software client. 

This appears to be an unnecessary burden on the parties involved to implement the parameters and maintain the 
parameters over time. 
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C.3.4 Proposed solution 



The mobile operator knows both the capabiHty of his network (e.g. Cell-ID + A-GPS) and the capability of the handset 
being utilized by the El 12 caller (e.g. has or does not have A-GPS or EOTD capability). 

The proposed solution is therefore that the emergency operator tells the mobile operator what type of fix is required (as 
in clause 10.1) and the mobile operator maps that request to the operator's appropriate location fix technology with 
whatever parameters are required for that operator's implementation). 

This functionality could be included in the protocol described in the present document by utilizing the LIF optional 
<loc_type> element and the addition of two new values to the element as follows. 



LIF 3.0 possible values 


Response Required 


<loc_type type='CURRENT' /> 


Refer to TS 122 071 and TS 129 002 for 
definition 


<loc_type type='LAST' /> 


Refer to TS 1 22 071 and TS 1 29 002 for 
definition 


<loc_type type='CURRENT_OR_LAST' /> 


Refer to TS 122 071 and TS 129 002 (see 
bibliograpliy) for definition 


<loc_type type='INITIAL' /> 


Refer to TS 1 22 071 and TS 1 29 002 (see 
bibliograpliy) for definition 


Proposed New Additions 




<loc type type='CURRENT FAST' /> 


Fastest possible current location fix is required 


<loc type type='CURRENT ACCURATE' /> 


Most accurate current location fix is required 



Note that in situations where: 

• only Cell-ID implemented; 

• or where EOTD or A-GPS is implemented but a fix is not available at the time; 

the response to both requests may in fact be the same (e.g. Cell-ID). 

The response elements <EllipticalArea> and <lev_conf> will enable the emergency operator to determine the accuracy 
of the response. 



The emergency location immediate request (see clause A. 1) would then become (addition in italics) as illustrated in the 
XML example below. 



XML Code 


Notes 


<?xml version="1.0" ?> 




<!DOCTYPE SVC init SYSTEM "MLP SVC INIT 300.DTD"> 




<svc init ver="3.0.0"> 


Service initiation for MLP Version 3.0.0 


<hdrver="3.0.0"> 


Header for MLP Version 3.0.0 


<client> 


Who is requesting this location fix 


<id>aaaa....a</id> 


Emergency operator registered user name for login 


<pwd>aaaa. . . a</pwd» 


Optional - Emergency operator password for login 


</client> 




</hdr> 




<eme_lir ver="3.0.0"> 


Emergency Location Immediate Request for MLP 
Version 3.0.0 


<msids> 


Identifier of device to be located 


<msid type="MSISDN">ccpppppppppp</msid> 


Identifier is a MSISDN formatted as Country Code + 
Phone Number (GSM/3GPP should conform to 
TS 123 003, see bibliography) 


</msids> 




<loc_type type='tttt....t' /> 


Where "tttt....t" is eitlier "CURRENT FAST" or 
"CURRENT ACCURATE" 


</eme lir 




</svc init> 
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C.3.5 Proposed action 



Propose the addition of the CURRENT_FAST and CURRENT_ACCURATE values to the <loc_type> element within 
MLP at the LIF meeting in September 2002. 



C.4 Proposed additional functionality - HTTP 1.1 
pipelining 

C.4.1 Background - out of order responses 

Another issue with the implementation of more than one location technology by a MNO is that it is possible that the 
response to one enquiry which utilizes an accurate slow response technology (e.g. A-GPS) may block the response to a 
subsequent inaccurate quick response technology (e.g. Cell-ID) since the HTTP responses to HTTP request messages 
must be in the same order as the HTTP requests were received. 

MLP 3.2 allows the emergency location immediate request to be specified as asynchronous. This allows responses to be 
returned when available and consequently not in the order they were received. 

Emergency services require the quickest possible response to requests for the location of a caller. 

It is therefore proposed that the emergency operator will utilize pipelining as defined the HTTP 1.1 to enable them to 
submit requests for location sequentially without waiting for a response. 

Under HTTP 1 . 1 responses should be returned in the same order as the requests were received. 

C.4.2 Issue 

For emergency operators the following use case is unacceptable. 

Assume that an operator has implemented both Cell-ID and A-GPS based positioning technologies. 

If the emergency operator submits a location request for one MSISDN which causes the network to initiate an A-GPS 
fix and then immediately follows it with a request for another MSISDN which causes the network to initiate a Cell-ID 
based fix, then following the HTTP 1 . 1 standard the operator cannot return the cell-ID based location result until it has 
returned the A_GPS based location result. 

As the A-GPS based fix may take 30 s to 60 s and the Cell-ID based fix may take only 1 s to 2 s the potential delay of 
28 s to 59 s in returning the cell-id based result to the emergency operator in unacceptable. 

C.4. 3 Proposed solution 

C.4. 3.1 HTTP 1.1 non conformance 

Return results to emergency operator from network as each result is available. This implies that the results returned may 
not be in the same order that the requests were received as required by HTTP 1.1. 

C.4.3.2 Utilize a transaction ID 

In order that the emergency operator can match potentially out of order responses with the appropriate request a 
transaction ID needs to be added by the emergency operator to each request and the same transaction ID returned by the 
operator with each valid response or error response. 

Note that because of dropped calls it is possible that the emergency operator may submit a request for an MSISDN 
before a previous request for the same MSISDN has been responded to. Therefore the MSIDN is not sufficient to match 
requests and responses. 
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C.4.4 Proposed action 

Add a transaction ID element to MLP. 
Add a Life-pulse message sequence to MLP. 



C.5 Location report - Network initiated push service 

FFS 
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Annex D (informative): 
Bibliography 

EPSG guidance notes documentation (see Guidance notes). 



ETSI TS 123 003: "Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications 
System (UMTS); Numbering, Addressing and Identification (3GPP TS 23.003)". 

ETSI TS 122 071; "Digital cellular telecommunications system (Phase 2+) (GSM); Universal Mobile 
Telecommunications System (UMTS); Location Services (LCS); Service description, Stage 1 (3GPP TS 22.071)". 

ETSI TS 129 002: "Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications 
System (UMTS); Mobile AppUcation Part (MAP) specification (3GPP TS 29.002)". 

ETSI EN 300 356 (all parts): "Integrated Services Digital Network (ISDN); Signalling System No. 7 (SS7); ISDN User 
Part (ISUP) version 4 for the international interface". 

W3C rec-xml- 199802 10: "Extensible Markup Language (XML) 1.0". 

NOTE: Available at http : //www . w3 c . org 
IETF RFC 2616: "Hypertext Transfer Protocol - HTTP/1.1". 

NOTE: Available at http://www.ietf org 
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